最小限で基礎的なセキュリティガイダンスである「AWS Startup Security Baseline (AWS SSB)」を紹介します

いわさです。

SaaS on AWS では大きく 4 つのフェーズ（設計・構築・ローンチ・最適化）で役立てる事ができるコンテンツが提供されています。
設計フェーズでは技術面からコンプライアンスに準拠したりセキュリティベースラインを考える必要があります。

これらについてベストプラクティスが提案されている動画コンテンツがあります。

https://www.youtube.com/watch?app=desktop&v=ha63-RZWcHY

その中で初期段階で実施出来ることとして次のステップが紹介されていました。

セキュリティ周りは Well-Architected Framework や Security Hub の適用から始めることも多いと思いますが、様々な制約からすぐの導入が難しい場合もあります。

そんな方に本日は上記の中の AWS Startup Security Baseline (AWS SSB) を紹介します。
意外に聞いたことが無い方も多いのではないでしょうか。手軽に導入し始めることが出来る内容となっています。

AWS Startup Security Baseline (AWS SSB)

AWS Startup Security Baseline (SSB) は大きくは「AWS アカウントの保護」と「ワークロードの保護」の２つから構成された ガイドライン です。何らかのベースラインをキープするコントロールをデプロイする感じではないです。
Well-Architected Framework の場合は設問ベースで、自分のワークロードだとどうなのかを判断しながら選択していく形になるのですが、このガイドラインでは「これやっとけ」という内容が列挙されており、手軽に導入することが出来ます。

ベースラインの内容は次のドキュメントに記載されています。

https://docs.aws.amazon.com/prescriptive-guidance/latest/aws-startup-security-baseline/welcome.html

抜粋したものを本記事にも記載しておきます。
それぞれの項目では設定手順も紹介されており、非常に使いやすいと思います。

なお、AWS SSB は AWS Well-Architected フレームワークのセキュリティの柱に沿っています。
推奨されているコントロールは、本質的に基礎的なものです。
次のステップとして必要に応じて追加のコントロールを追加する必要があります。

アカウントの保護

アカウント保護では次の 12 個の項目に対処することで AWS アカウントのセキュリティ保護を行います。

• ACCT.01 – アカウントレベルの連絡先を有効なメール配信リストに設定する
• ACCT.02 – ルートユーザーの使用を制限する
• ACCT.03 – 各ユーザーのコンソールアクセスを構成する
• ACCT.04 – 権限の割り当て
• ACCT.05 – ログインに多要素認証 (MFA) を要求する
• ACCT.06 – パスワードポリシーの適用
• ACCT.07 – CloudTrail ログを保護された S3 バケットに配信する
• ACCT.08 – プライベート S3 バケットへのパブリックアクセスを防止する
• ACCT.09 – 未使用の VPC、サブネット、セキュリティ グループを削除する
• ACCT.10 – 支出を監視するために AWS 予算を設定する
• ACCT.11 – GuardDuty 通知を有効にして応答する
• ACCT.12 – Trusted Advisor を使用して高リスクの問題を監視し、解決する

内容を見てみると、どれも AWS アカウント作成後に最低限設定しておくべきものという印象です。

また、クラスメソッドでは次のように「AWS アカウントで最初にやるべき設定」という観点でより充実したガイドを出しています。
AWS SSB よりも対応労力は必要かもしれませんが、次のステップとしてこちらも是非参考にして頂けると良いのではないでしょうか。

https://dev.classmethod.jp/articles/aws-baseline-setting-202206/

ワークロードの保護

ワークロードの保護では次の 15 個の項目に対処することで、AWS アカウント上にデプロイする個別のワークロードのセキュリティ保護を行います。

• WKLD.01 – コンピューティング環境の権限に IAM ロールを使用する
• WKLD.02 – リソースベースのポリシー権限で資格情報の使用範囲を制限する
• WKLD.03 – 一時的なシークレットまたはシークレット管理サービスを使用する
• WKLD.04 – アプリケーションシークレットの漏洩を防ぐ
• WKLD.05 – 公開された秘密を検出して修復する
• WKLD.06 – SSH または RDP の代わりに Systems Manager を使用する
• WKLD.07 – 機密データを含む S3 バケットのデータイベントをログに記録する
• WKLD.08 – Amazon EBS ボリュームの暗号化
• WKLD.09 – Amazon RDS データベースの暗号化
• WKLD.10 – プライベートサブネットにプライベートリソースをデプロイする
• WKLD.11 – セキュリティ グループを使用してネットワーク アクセスを制限する
• WKLD.12 – VPC エンドポイントを使用してサポートされているサービスにアクセスする
• WKLD.13 – すべてのパブリック Web エンドポイントに HTTPS を要求する
• WKLD.14 – パブリックエンドポイントにエッジ保護サービスを使用する
• WKLD.15 – テンプレートでセキュリティ制御を定義し、CI/CD プラクティスを使用して展開する

これらは設定しておくというものよりも設計時点で意識しておくものという感じですね。
これらもどれも必要最低限なものが記載されていると思いますので基本的に全部対応する形が良い印象です。

よくお客様から「はじめて外部公開するサービスを作成することになったのだが、セキュリティ上どうしたら良いのか」というお問い合わせをいただくことがあります。
上記ではパブリックアクセスを想定した項目（エッジ、WAF、セキュリティグループなど）もあり、そういったケースでもご利用頂けると思います。

さいごに

本日は、最小限で基礎的なセキュリティガイダンスである「AWS Startup Security Baseline (AWS SSB)」を紹介しました。

内容を見ると本当に基礎的で最小限という感じではありますが、使い始めたばかりだと未設定であったり、ナレッジがなければ設計時にも意識しないものもあります。
AWS アカウント、ワークロードの双方の観点でそれぞれ保護出来るのもとても良いですね。

セキュリティ保護のはじめの一歩として導入してみては如何でしょうか。